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(57) Abstract: A system for accessing storage on a server by 
clients on a network includes software on the server to process 
requests and allocate storage based on client needs. The clients 
include a special BIOS and a disk drive controller proxy. The 
BIOS retrieves operating system software, drivers, and other 
application software from the server. The disk drive controller 
proxy routes disk requests to the server for processing. In some 
embodiments, clients may share storage on the server. 
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PROVIDING CLIENT ACTFS SIBLE NETWORK-BASED STORAGE 

Background 

This invention relates to client-server environments and, more particularly, 
to diskless clients. 

As the average selling price of personal computers declines, computer 
manufacturers often look for ways to more efficiently serve the market. In a 
client-server network environment, many redundancies may exist which present 
opportunities for computer manufacturers. 

One possible redundancy is the use by several clients on a network of the 
same operating system and/or application programs. The vast majority of clients 
in a small business or educational environment have storage space that is 
identical and redundant. In particular, the storage space used for the operating 
system (such as Microsoft Windows) and the office productivity applications can 
take up to one gigabyte of space on a modern client. However, this is duplicated 
amongst the various clients. 

The idea of a diskless client or diskless workstation is not new. However, 
with the advent of a 100 Mbit Ethernet Network Connection, a diskless client may 
become more practical. The server for these diskless clients may be designed to 
offer each client an amount of disk storage dedicated for that client. The space 
on the server would be the equivalent of a "C" drive (or main hard disk drive) for 
20 the client. 

One way to optimize server storage for diskless clients is to divide the 
client's files into two categories: shared and private. Those files that are normally 
shared by all clients are loaded into a different directory structure than the private 
files. Microsoft used this implementation to support diskless clients in Windows 
25 95. However, this implementation is problematic because most applications do 
not install and work properly when operating system files are loaded into more 
than one directory structure. In part because of this, Microsoft chose to drop the 
diskless support after Windows 95. 
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Other attempts to support diskless clients have been made. These 
methods tend to be highly complex and focus on using a higher-level file system 
protocol, such as the Network Hie System (NFS). However, particularly n low- 
end small business environments with very simple networks, such solutions may 

5 be too complex. 

Thus, there is a continuing need to provide a diskless client-server 
environment that works seamlessly with operating system and other software. 

RriPf Descrir """ nf thp Drawings 
Figure 1 is a block diagram of a system according to one embodiment of 

10 the invention; 

Rgure 2 is a flow diagram of the client request processor according to one 

embodiment of the invention; 

Figure 3 is a block diagram of the drive apportionment software accord.ng 

to one embodiment of the invention; 
15 Figure 4 is a detailed block diagram of the drive apportionment software 

according to one embodiment of the invention; 

Rgure 5 is a flow diagram of operation of the drive apportionment software 
according to one embodiment of the invention; 

Rgure 6 is a block diagram of the driver apportionment software using a 
20 cached according to one embodiment of the invention; 

Rgure 7 is a flow diagram of the specialized BIOS of the client according to 

one embodiment of the invention; 

Rgure 8 is a flow diagram showing operation of the client virtual boot 
record according to one embodiment of the invention; 
25 Rgure 9 is a flow diagram showing operation of the disk drive controller 

proxy according to one embodiment of the invention; and 

Rgure 10 is a block diagram of the system according to one embod.ment 
of the invention. 
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Detailed Descri ption 
The following describes a system for providing network-based storage to 
clients on a network. For purposes of explanation, specific embodiments are set 
forth to provide a thorough understanding of the invention. However, it will be 
5 understood by one skilled in the art that the invention may be practiced without 
the particular details described herein. Further, although the embodiments are 
described in terms of hard disk drive storage media, the illustrated system may be 
applied to other non-volatile media, including, but not limited to compact disk 
read-only memories (CD ROMs), optical storage media, tape drives, flash 
10 memories, and option ROMs. Moreover, well-known elements, devices, process 
steps, and the like, are not set forth in detail in order to avoid obscuring the 
invention. 

In accordance with the several embodiments described herein, a server 
system on a network may support a plurality of diskless clients. Where possible, 

15 software on the server, and thus storage space, is shared between the diskless 
clients, providing an efficient network. Using specialized firmware on the client, 
the client is able to communicate with software on the server to redirect disk 
accesses. By providing a proxy for the disk drive controller on the client, 
operating system and other software operate as though the client has a local hard 

20 disk drive. 

In Figure 1, a system 100 includes a server 50 and a client 30, both 
connected to a network 40. The server 50 and the client 30 are both processor- 
based systems. In one embodiment, the server 50 and client 30 are connected to 
the network 40 using a fast Ethernet Local Area Network (LAN) protocol, which 

25 supports data transfer rates of 100 megabits per second. 

In one embodiment, the server 50 includes a plurality of software 60. For 
example, a client request processor 150 receives network packets indicating hard 
disk drive requests from the client 30. The client request processor 150 translates 
these requests such that other software 60 on the server 50 may process them. 

30 The client request processor 150 further translates results from operations 

performed on the server 50 such that they may be transmitted back to the client 

3 
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30. The client request processor 150, according to one embodiment, is described 

in connection with Figure 2, below. 

The server software 60 further includes drive apportionment software 200. 
The drive apportionment software 200 receives hard disk drive access requests 
from the client request processor 150. The drive apportionment software 200 
services the requests based upon a particular mapping of the hard disk drive on 
the server 50. The drive apportionment software 200, according to several 
embodiments, is described in more detail in connection with Figures 3 through 6, 

below. . __ n 

The sewer 50 further includes one or more dient virtual boot records 250. 

The client virtual boot record or records 250, in one embodiment, may be 
downloaded to the dient 30 following a request by the dient 30 to boot In some 
embodiments, the server 50 indudes more than one client virtual boot record 
250 such that the various dients 30 on the network 40 may be fteobly 
configured. The dient virtual boot record 250, according to one embodiment, is 
discussed in connection with Figure 8, below. 

In one embodiment, the sewer 50 further includes a dient drive redirect™ 
driver 300. The dent drive redirection driver 300, like the dient virtual boot 
recort 250, is downloaded to the client 30 during initialization. The dnve 
»0 redirect driver 300 receives requests to access a hard disk drive, which is not 
" present on the Cent 30. Once loaded on the dient 30, the drive redirection 
driver 300 transmit the request, over tine network 40 to the server 50, such *at 
tine requests may be serviced on the hard <■* drive of the sewer 50. The Cent 
drive redirection driver 300, according to one embodiment, is also described ,n 
25 connection with Figure 8, below. 

,„ addition to the software 60 on the sewer 50, the client or dients 30 
indude boti, a spedalfced basic input/output system (BIOS) 350 and a disk drive 
conti*r prexy 400. In one embodiment, the spedalfced BtOS 350 . , part o, > 
memory 62. such as a read-on* memow (ROM). The specked IOS 35 
assists the client 300 during power on such that the dlen, 30 is connected . *. 
network 40, recedes the attention of the sewer 50, receives tire wrtua, boet 
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record 250 from the server 50, and receives the drive redirection driver 300 from 
the server 50. Together, these operations permit the diskless client 30 to 
nevertheless service disk drive requests. The specialized BIOS 350, according to 
one embodiment, is discussed in connection with Figure 7, below. 
5 The disk driver controller proxy 400, in one embodiment, causes software 

running on the client 30 to believe that a disk drive controller is present on the 
client 30. Thus, software operating on the client 30 sends a disk drive request to 
the disk drive controller proxy 400, just as the software would send a request to a 
real disk drive controller. However, in some embodiments, the disk drive 
10 controller proxy 400 may operate differently than a disk drive controller. Instead, 
in one embodiment, the disk drive controller proxy 400 encapsulates the disk 
requests in packets such that they may be transmitted over the network 40, and 
ultimately serviced by the drive apportionment software 200 of the server 50. 

The disk drive controller proxy 400 may also receive packets from the 
15 network 40 and return the drive results to the requesting software. In one 
embodiment, the disk drive controller proxy 400 is hardware-based, embedded in 
a multi-purpose chip, such as a southbridge controller chip. In a second 
embodiment, the disk drive controller proxy 400 is firmware, stored in the ROM 
62 of the client 30. The disk drive controller proxy 400, according to one 
20 embodiment, is discussed in more detail in connection with Figure 9, below. 

The client request processor 150 may receive disk requests from the client 
30 encapsulated as network packets, as well as transmit responses to the disk 
operations back to the client 30. In Figure 2, the operation of the client request 
processor 150, according to one embodiment, begins by receiving by a packet 
25 over the network 40 on behalf of the client 30 (block 152). In one embodiment, 
the packet is an Ethernet packet. However, the packet may be transmitted using 
other protocols. 

From the packet, the client request processor 150 extracts a drive request 
from the encapsulated packet (block 154). The client request processor 150 then 
30 calls the drive apportionment software 200 (block 156). The drive apportionment 
software 200, in one embodiment, translates the drive request by the client 30 
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«, a local storage request, that * a re q uest for the hard disk drive of the server 

50 ' After sen,icing *e drtve request, the eHent request processor 150 recefc* 
one or more results ftom *e drtve apportionment soft^ 200 (M 1» 
5 R ^ing the prior operadons, the *nt request pmcessor 150 encapsulates * 
rlufts 1 padtets (biock 160), such mat the packets may be transmfced 

orocessor 150, according to one embodiment, is complete. 
""Il dre drtve appo— software 200 * caled by the 
10 processor 150, the request may he serviced in a number of 

I server 50 may allocate a dsdnct portion of Ks storage sp^ to <** 
requesdng client 30 on the network 40. On a typicai nebvo*, each Cent 30 may 
STL OP-* sy^m or may use the same 
another client on the neUvo* 40. Thus, according to one embod meat, the 
B XtOO allocates server 50 storage «. this common usage mode, ,n ™* 
^ „ Figure 3, acting to one ^bodiment, the server » 

u _ c «, hard disk drive 80, including a common storage region 
volatile storage, such as a nara ais* unvc W/ 

40 in a second embodiment, the non-voMIe storage ,s an opbcal M. 
» in Bgure 3, the network 40 indudes die* 30a, dient 30b, and *n, Oc 

2 Accord* the L. disk drtve 80 includes dient private storage 84a, d,ent 

25 of the hard disk drive 80. In one embodiment, ft memory 

22 one for each dient 30, to supply this informabon. For each dient , 

30 service requests from the client 30. 
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Each bitmap 22 is comprised of a plurality of bits. In one embodiment, 
each bit represents a sector of disk storage available to each client 30, as 
between the common storage 82 and the private storage 84. Further, in one 
embodiment, the location of the bit 12 in the bitmap 22 represents the location of 
5 the sectors in the common storage 82. 

In Figure 4, the client bitmap 22a, according to one embodiment, is located 
in the memory 20 of the server 50, and includes a plurality of bits 12. In one 
embodiment, the number of bits 12 in the client bitmap 22a represents the 
number of sectors available to the client 30a, while the number of bits 12 set to a 
10 "1" represents the number of private sectors available to the client 30a. 

In Figure 4, the common storage 82 of the server 50 includes a plurality of 
sectors 86. Each bit 12 of the client bitmap 22a initially represents each sector 86 
of the common storage 82. However, in one embodiment, each time a bit 12 is 
set in the client bitmap 22a, a copy of the sector 86 is copied from the common 
15 storage 82 to the client private storage 84a as a private sector 88. 

In addition to identifying the number of sectors available to the client 30a, 
the bitmap 22a further may identify the location of the requested sector 86 on the 
hard disk drive 80. For example, in one embodiment, a w 0" in the bitmap 22a for 
bit 12 in the third position directs the drive apportionment software 200 to 
20 retrieve the third sector from the common storage 82 of the hard disk drive 80. 

By contrast, a "1" in the bitmap 22a for the ninth bit, bit 12a in Figure 4, 
indicates that the sector to retrieve was originally in the ninth position, sector 86a 
in Figure 4, of the common storage 82. However, the sector 86a has previously 
been copied to the client private storage 84a as private sector 88a. Because bit 
25 12a is the first non-zero occurrence in the client bitmap 22a, the first private 
sector 88a is retrieved from the client private storage 84a. Thus, the "1" in bit 
12a of the bitmap 22a directs the drive apportionment software 200 to retrieve 
the first private sector 88a from the private storage 84a on behalf of the 
requesting client 30a. Programmers of ordinary skill in the art recognize this as 
30 but one of several possible implementations of the client bitmap 22a. 
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Thus, when all bits 12 in ft. bitmap 22a are set «o V. the dnve 
apportionment software 200 refteves ,1, sector read reques* ftom fte comrnon 
Z» 82 of fte hard disk drive 80. For son* systems 100, fte common storag 
area 82 may service fte vast majority of aoesses by the Cents 30 on fte 
ne^ork 40. For example, fte loading of operahng system and ofter app cabon 
»lre «** involves only read operabons. According,,, dent 30a and Cent 
SoTmay Ire idenbca, operabng system severe located in fte common 
storage area 82 of fte hard disk drive 80. 

Occasionally, fte client 30 may perform write operabons to ,ts «M 
, ^e. in one embodiment when a sector write operator , is 

*nt 30, the bit 12 corresponding to the requested sector 86 ,s set ft a (fta 
U t fte bit 12 has not already been set). The reievant sector 86 Is copred ft the 
, te „ private storage 84 as private sector 88, where fte write operabon may 
Si* * perforated. Once a wr*e ft a sector Is made a subsequent 
5 accesses to fte sector are from fte private storage 84 of fte c ent 30 

in Figure 4, four bits of fte client 30 bitmap 22a are set to a 1 , 12a 12b, 
nc and 12d. UkewSe, four seCors 86 of fte common storage 82, X* «■ «- 
and 86d, are copied ft fte Cent prwate storage 84a, as pnvato seders 88a, 8*, 
8^ an 884. Thus, In one embodiment, fte number of bits 12 wh,ch are se to 
» ™ client biftrap 22 represents fte number of prtvato sectors 88 located ,n 

embodiment, begins by receiving fte hard disk drive 80 ~ " 
h„m the Cent request processor 150, on behalf of fte Cent 30 (bfcck 202V n 
25 Toe embodiment, al, read requesft are «a«y serviced hem fte — ~£ 
Tof fte hard disk dnve 80. However, once a sector 86 k cop,ed as a pmrate 
HZ and the private sector 88 Is written to, subsequent read requests fte 
7Z » are directed to fte private storage 84 of fte Cent 30 and ft 
^aated prfvate sector 88. — , fte drfve ~ 2 °° 

determines whefter a read or a wrtft request is being made (d,amond 204). 
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If a read request is made, the drive apportionment software 200, running 
on the server 50, accesses the bitmap 22 of the client 30 from the memory 20 of 
the server 50. The bit 12 for the requested sector is tested (diamond 206). If 
the relevant bit 12 is set, a prior write operation to the private sector 88 may be 
presumed. If the bit 12 is not set, the requested sector 86 is retrieved from the 
common storage 82 of the server 50 (block 208). The requested sector 86 is then 
sent to the client request processor 150 (block 210). From there, according to 
one embodiment, the client request processor 150 sends the result across the 
network 40 to the client 30. 

If the relevant bit 12 of the client's bitmap 22 is set (diamond 206), then, 
although this is a read request, the private sector 88 is retrieved from the private 
storage 84 of the client 30 (block 212). The retrieved private sector 88 is then 
sent to the client request processor 150, where it is packetized and transmitted to 
the client 30 over the network 40. 

To process write requests (diamond 204), the drive apportionment 
software 200 reads the bitmap 22 of the client 30 to determine if the relevant bit 
12 is set (diamond 214). If so, the requested sector is already in the private 
storage 84 of the client 30 as private sector 88. Accordingly, the private sector 88 
is identified (block 220), then a write operation is performed on the private 
20 sector 88 in the client private storage 84 (block 222). 

If, however, the relevant bit 12 is not set in the client bitmap 22, the 
requested sector 86 is copied from the common storage 82 and stored as private 
sector 88 in the private storage 84 of the client 30 by the drive apportionment 
software 200 (block 216). The relevant bit 12 is then set in the client bitmap 22 
(block 218). This ensures that subsequent retrievals are to the private sector 88 
in the private storage 84 of the client 30, not from the sector 86 in the common 
storage 82. The requested private sector 88 is then written to in the private 
storage 84 of the hard disk drive 80 of the server 50 (block 222). Thus, the 
operation of the drive apportionment software 200, according to one 
embodiment, is complete. 
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In some embodiments, much of the frequently used portions of the 
common storage 82 of the server 50 may be stored in a cache, such as a memory 
cache. In this way, read requests from the client 30 may be honored from in- 
memory cache, rather from the common storage 82 of the hard disk drive 80. In 
5 other embodiments, a processor cache is used to store commonly used portions 
of the common storage 82. The use of a cache may further speed operations 
such as booting or launching a productivity application by the client 30. 

In Figure 6, the server 50 includes the common storage 82, just as in 
Figure 4. The server 50 further includes a cache bitmap 24, which, like the client 
10 bitmaps 22, may be located in the memory 20 of the server 50. 

The memory 20 may further include a server cache 44. Like the client 
private storage 84 of Figure 4, the server cache may be used to transfer the 
sectors 86 from the common storage 82 as new sectors 92, such as for sectors 
which are frequently used. Unlike the client private storage 84, which is located 
15 on the hard disk drive 80, the server cache 44 is located in the memory 20. Thus, 
in one embodiment, accesses to the sectors 92 in the server cache 44 may be 
serviced at a substantially higher speed than those to the hard disk drive 80 of 
the server 50. In Figure 6, the frequently used sectors, 86e through 861, as 
indicated by the bits 12e through 121 in the cache bitmap 24, are accessible in the 
20 server cache 44 as sectors 92e through 921. 

In another embodiment, the client bitmaps 22 as well as the cache bitmap 
24 may identify blocks different from a sector in size for movement to the client 
private storage 84 or the server cache 44. A hard disk drive sector is typically 512 
bytes in length. However, modern file systems often deal with block sizes of 
25 seven sectors. The larger block size is used so that the file system runs more 
efficiently. So, for example, if a single sector is changed in the middle of a seven 
sector file system block, according to one embodiment, all seven sectors may be 
copied into the private storage 84 of the client 30 (or into the server cache 44). 
Accordingly, the bit 12 corresponding to the seven sector block may be set. 
30 In yet another embodiment, the client bitmaps 22 and the cache bitmap 24 

may be reset such that all bits 12 in the bitmap 22 are cleared to "0". For a client 
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bitmap 22, this state may be identified as a default state of the client 30. The 
ability to reset the client 30 to a default state may be particularly useful in 
environments where the user of the client 30 changes. For example, in an 
educational setting, a student user may change on the client 30 every six months 
5 to a year. 

Looking back to Figure 1, the client request processor 150 and the drive 
apportionment software 200, in one embodiment, are not run until the client 30 
establishes a connection to the server 50. The specialized BIOS 350 of the client 
30 engages the server 50, such that the client 30 may receive the virtual boot 

10 record 250 as well as the one or more client drive redirection driver 300 from the 
server 50. Additionally, the disk drive controller proxy 400, "fakes out" any 
application software executed by the client 30, such that hard disk drive 
operations may be successfully performed on the client 30 even though the client 
30 itself has no hard disk drive. 

15 In short, according to one embodiment, the specialized BIOS 350 of the 

client 30, soon after the client 30 powers on, retrieves the virtual boot record 250 
and the client drive redirection driver 300 from the server 50. Once received, the 
virtual boot record 250 is executed on the client 30. During this time, any hard 
disk drive accesses, which are attempted by the virtual boot record 250, are 

20 redirected by the drive redirection driver 300 such that the disk drive controller 
proxy 400 of the client 30 is instead accessed. Then, the disk drive controller 
proxy 400 performs disk operations by accessing the hard disk drive 80 of the 
server 50. 

As illustrated in Figure 2, the packets comprising disk requests sent by the 
25 disk drive controller proxy 400 to the server 50 are handled by the client request 
processor 150. The disk drive controller proxy 400 operates from the perspective 
of the requesting boot record 250 (or any other application software), as though 
the drive operations are performed locally. Thus, the client 30 may support 
operating system and other software, some of which depend upon the presence 
30 of a hard disk drive, while, in fact, having no hard disk drive. 

11 
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In Figure 7, the operation of the specialized BIOS 350, according to one 
embodiment, starts by connecting the client 30 to the network 40, for access to 
the server 50 (block 352). The specialized BIOS 350 next broadcasts a request 
for the server 50 (block 354). In one embodiment, the client 30 and the server 
5 50 operate as part of a pre-boot execution environment (PXE). The PXE 
Specification (Version 2.1, September 20, 1999) is available from Intel 
Corporation, Santa Clara, California. The client 30 initiates the PXE protocol by 
broadcasting a particular command that identr.es the request as coming from a 
client that implements the PXE protocol. After several intermediate steps, the 
10 server 50 sends the client 30 a list of appropriate boot servers. The client 30 then 
discovers a boot server of the type selected and receives the name of an 
executable file on the chosen boot server. 

In one embodiment, the executable file received by the client 30 is the 
client virtual boot record 250 (block 356). Further, the specialized BIOS 350 
15 retrieves the client drive redirection driver 300, also from the server 50 (block 
358) Finally, the specialized BIOS 350 executes the virtual boot record 250 
(block 360). For example, the specialized BIOS 350 may perform a BIOS funcbon 
INT19h in order to execute the virtual boot record 250, which is loaded in a cl.ent 
memory. Thus, the operation of the specialized BIOS 350, according to one 

20 embodiment, is complete. 

Now that the client virtual boot record 250 is loaded in the client memory, 
the virtual boot record 250 may be executed. Note that when the boot record is 
located on the hard disk drive, it is typically loaded into memory and executed. 
Although retrieved from a remote hard disk drive, the virtual boot record 250 thus 

25 also operates in this manner. 

In Figure 8, the operation of the client virtual boot record 250, according to 
one embodiment, begins by Issuing a command to load an operating system core 
(block 252). in the prior art, the operating system is typically loaded by issuing 
mm functions tor retrieving the operating system from the hard disk dnve. 

30 Here, instead, the drive redirection driver 300, received from the server 50 by the 
specials BIOS 350, sends a request to the disk drive controller proxy 400 (block 
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254). In other embodiments, instead of using a driver to intercept the INT13h 
functions, the specialized BIOS 350 may itself redirect all INT13h functions to the 
disk drive controller proxy 400. 

To process the request, in one embodiment, the disk drive controller proxy 
5 400 retrieves the operating system from the server 50, using a protocol as 
described in connection with Figure 9, below (block 256). The operating system 
core is then loaded into the client memory (block 258). Once loaded, the 
operating system is executed (block 260). For all subsequent disk drive requests 
(e.g., run time requests), the drive redirection driver 300 may service the 
10 requests (block 262). Thus, according to one embodiment, the operation of the 
client virtual boot record 250 is complete. 

The disk drive controller proxy 400, invoked by the client virtual boot 
record 250 may look likes a normal disk drive controller to software running on 
the client 30, in one embodiment. This means that the disk drive controller proxy 
15 400 receives disk access requests. The operation of disk drive controller proxy 
400, according to one embodiment, is described in connection with Rgure 9. 

First, the disk drive controller proxy 400 receives a request from operating 
system or other software loaded on the client 30, to access a hard disk drive 
(block 402). The disk drive controller proxy 400 encapsulates this disk request 
20 into packets suitable for transmission across the network 40 (block 404). 

In one embodiment, the client 30 employs a protocol for requesting sector 
accesses across the network 40 to the server 50. The protocol includes a private 
command and reply structure, including a command header section, a data 
content section, and an error handling section. Because the client request 
25 processor 150 is available for receiving the requests by the server 50, the 
commands from the disk drive controller proxy 400 may be simple, like "read 
sectors a, b, c, d" or "write sectors e, f, g, h". 

Next, according to one embodiment, the disk drive controller proxy 400 
sends the packet with the encapsulated disk request over the network 40 to the 
30 server 50 (block 406). The disk drive controller proxy 400 then waits for a 
response from the server 50. 
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At some point, the disk drive controller proxy 400 receives the response 
packet, including the d te k result, from the dient request processor 150 of the 
server 50 (block 408). The disk drive confer proxy 400 next de-encapsu, mm 
drive result from the packet as drive resuK da* (bkx* 410). Tne result dato 
5 may then be stored in the memory of the Cent 30 (blodk 412), such ft* ft. data 
ma y be retrieved by the requesting applicadon. Thus, the operahon of the d.k 
drive controller proxy 400, according to one embodiment, is complete 

Referring to Figure 10, the server 50 includes a processor 10, and the 
memory 20, including the cache 44, as described In connection with Frgure 6, 
M above. The processor 10 may comprise a microcon.ro,*, an X86 microprocessor 
an Advanced RISC Machine (ARM) microprocessor, or a Penbum-based 
microprocessor, to name a few. The memory 20 may comprise 
random access memories, such as dynamic random access memones p«M* 
synchronous DRAMs (SDRAMs), stabc RAMs (SRAMs), single ,n-lme memon, 
15 modules (SIMMs), or double in-line memory modules (DIMMs), to name a few. 

Both the processor 10 and the memory 20 are connected via a system bus 
,4 in one embodiment, a bridge chip 16 is also coupled to the system bus 14 
slrc „ as for Induding a second bus 18, such as a peripheral componen 
interconnect (PCI) bus 18. The Pd specfflcabon is available from the PQ Spec®. 
20 interest Group, Portland, Oregon 97214. 

h one embodiment, the bridge chip 16 further supports the hard MM 
80, indudir* the sofbvare 60 as shown in connecbon w«t Figure 1, The POte 
18 may also support a networx interface cerd (NIC) 42, for connecbng the server 

50 to the network 40. 
25 The dient 30 is also a processor-based system, Induding a 

me mory 64, and the ROM 62, each coupled to a system bus 56. Uke the 
;Hr 1 on me server 50, me processor 58 may include any o a vane* o 
Z^s. AUO like the server 50, the memory 64 may be any of a vane* o, 
random-access memories. 
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As in Figure 1, the ROM 62 includes the specialized BIOS 350. The ROM 
62 may be a programmable ROM (PROM), an erasable programmable ROM 
(EPROM), and electrically erasable PROM, and so on. 

Like the server 50, the client 30 includes a bridge chip 52 coupled between 
5 the system bus 56 and a PCI bus 48. The PCI bus 48 may also support a NIC 
card 46, for connection to the network 40. In one embodiment, the disk drive 
controller proxy 400, as in Figure 1, may be part of the multi-function bridge chip 
52. In other embodiments, the disk drive controller proxy 400 may be a separate 
and distinct component, coupled to the system bus 56 or the PCI bus 48. The 
10 embodiment of Figure 10 thus represents one of many possible implementations 
of the illustrated system 100. 

Thus, in some embodiments, a system for supporting diskless clients 
exploits the redundant needs of the clients on a network. Where possible, the 
client may share accesses to the hard disk drive of the server. The clients 

15 nevertheless may maintain private storage on the server, where needed. In some 
embodiments, the client includes a specialized BIOS for establishing connection to 
the server and downloading an operating system. In some embodiments, the 
client further includes a drive controller proxy for re-routing drive requests to the 
server. The server likewise includes specialized software, for servicing the remote 

20 requests, for allocating drive space to the various clients, and for downloading 
operating system and driver software to the client, in some embodiments. 

While the present invention has been described with respect to a limited 
number of embodiments, those skilled in the art will appreciate numerous 
modifications and variations therefrom. It is intended that the appended claims 

25 cover all such modifications and variations as fall within the true spirit and scope 
of this present invention. 
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What is claimed is: 



1 A method, comprising: 

generating on a client a request to access a non-volatile storage; 
receiving the request by a non-volatile storage proxy on the cl.ent; 

5 accessing the non-volatile storage on a server by the non-volatile 

storage proxy. 

2 . The method of claim 1, accessing the non-volatile storage on a 
server by the non-volatile storage proxy further comprising: 

encapsulating the request into a packet suitable for transm,ss,on 

over a network; and 

sending the packet to a server connected to the network. 

3. The method of claim 2, further comprising: 
receiving the packet by the server; 
15 de-encapsulating the request from the packet; and 

producing a result based upon the request. 



The 



method of claim 3, producing a result based upon the request 

further comprising: 

identifying a block of the non-volatile storage on the server, 
performing an operation on the b«ock based upon the request; and 
receiving In the non-volatile storage proxy a result from the serve, 



5. The 



method of claim 4, identifying a block of the non-volatile 



storage on the server further comprising: 

accessing a table associated wito the client in a vo«ati«e memon, of 



25 the server; and 

**" lo 
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finding an entry in the table associated with the block. 

6. The method of claim 4, receiving in the non-volatile storage proxy a 
result from the server further comprising: 

receiving a second packet encapsulating the result produced by the 

5 server; and 

de-encapsulating the result from the second packet. 

7. The method of claim 5, further comprising: 
reviewing the entry associated with the block; 

identifying the block as having previously been written to by the 

10 client; and 

retrieving the block from a first portion of the non-volatile storage 
on the server wherein the first portion is associated with the client. 

The method of claim 5, further comprising: 
reviewing the entry associated with the block; 
identifying the block as not having previously been written to by the 

retrieving the block from a common portion of the non-volatile 
the server. 

The method of claim 5, further comprising: 
storing the result in a volatile memory of the client. 

10. A system comprising: 

a server, comprising a non-volatile storage; 
a network coupled to the server; and 

a client coupled to the network, the client including a non-volatile 
storage proxy that receives a storage access request and forwards the 
storage access request to the server over the network. 

17 
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U. The system of claim 10, wherein the non-volatile storage proxy 
forwards the storage access request to the server over the network by: 
encapsulating the storage access request into a packet; and 
sending the packet over the network to the server. 

12. The system of claim 1 1, wherein the server further: 
receives a packet from the client on the network; 
extracts the storage access request from the packet; and 
accesses the non-volatile storage in response to the storage access 



request. 



10 



13. The system of claim 12, wherein the server further: 

produces a result associated with accessing the non-volatile storage; 
encapsulates the result in a second packet; and 
sends the second packet over the network to the client. 



14. The system of claim 13, wherein the non-volatile storage proxy 



15 further: 



receives the second packet from the client over the network; 
de-encapsulates the result from the second packet; and 
sends the result to a memory on the client. 

15. The system of claim 10, wherein the client includes no non-volatile 



20 storage. 



25 



16. The system of claim 10, wherein the client further comprises a 

software program to: 

broadcast a server request on the network; 
retrieve a virtual boot record from the server; and 

execute the virtual boot record. 
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17. A system, comprising: 
a processor; 

a network interface for connecting the system to a network; and 
a non-volatile storage proxy coupled to the processor, wherein the 
5 non-volatile storage proxy: 

receives a non-volatile storage access request; 
encapsulates the non-volatile storage access request into a 

packet; and 

sends the packet out over the network interface to a server. 

10 18. The system of claim 17, wherein the non-volatile storage proxy 

further: 

receives a second packet from the server; and 
de-encapsulates a result from the second packet. 

19. The system of claim 18, wherein the result is produced by the server 
15 following an access to a non-volatile storage located on the server in response to 

the request received by the server from the system. 

20. The system of claim 17, further comprising: 

a non-volatile memory storing a software program executed during 
power-on of the system, wherein the program: 
20 broadcasts a request for the server on the network; 

retrieves a virtual boot record from the server; 
stores the virtual boot record in the memory; and 
executes the virtual boot record. 

21. The system of claim 20, wherein the program further: 

25 retrieves a redirection driver from the server; 

stores the redirection driver in the memory; and 
19 
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loads the redirection driver. 

22 The system of claim 21, wherein the drive redirection driver sends 
the request to access the non-voiatile storage to the non-volatile storage proxy. 

23. An article comprising a medium storing a software program that, 
5 upon execution, causes a processor-based system to: 

generate on the processor-based system a request to access a non- 
volatile storage; 

receive the request by a non-volatile storage proxy on the 

processor-based system; and 
10 access the non-volatile storage on a server by the non-volatile 

storage proxy. 

24 The article of claim 23, further storing software that, upon 
execution, causes a processor-based system to access the non-volatile storage on 
a server by the non-volatile storage proxy by: 
15 encapsulating the request into a packet suitable for transmission 

over a network; and 

sending the packet to a server connected to the network. 

25. The article of claim 24, further storing software that, upon 
execution, causes a processor-based system to: 
20 receive the packet by the server; 

de-encapsulate the request from the packet; and 
produce a result based upon the request. 

26 The article of claim 25, further storing software that, upon 
execution, causes a processor-based system to produce a result based upon the 
25 request by: 

identifying a block of the non-volatile storage on the server; 
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performing an operation on the block based upon the request; and 
receiving in the non-volatile storage proxy a result from the server. 

27. The article of claim 26, further storing software that, upon 
execution, causes a processor-based system to identify a block of the non-volatile 

5 storage on the server by: 

accessing a table associated with the processor-based system in a 
volatile memory of the server; and 

finding an entry in the table associated with the block. 

28. The article of claim 27, further storing software that, upon 
10 execution, causes a processor-based system to: 

review the entry associated with the block; 
identify the block as having previously been written to by the 
processor-based system; and 

retrieve the block from a first portion of the non-volatile storage on 
15 the server wherein the first portion is associated with the processor-based 
system. 

29. The article of claim 27, further storing software that, upon 
execution, causes a processor-based system to: 

review the entry associated with the block; 
identify the block as not having previously been written to by the 
processor-based system; and 

retrieve the block from a common portion of the non-volatile storage 
on the server. 

30. The article of claim 26, further storing software that, upon 
execution, causes a processor-based system to receive in the non-volatile storage 
proxy a result from the server by: 

21 
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receiving a second packet encapsulating the result produced by the 

server; and 

de-encapsulating the result from the second packet. 
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